This invention relates to online electronic commerce, and in particular to a secure methodology for approving an online transaction carried out over the Internet by authenticating the identity and credit of the purchaser without transmitting a credit card number or other payment means as part of the online transaction.
The Internet is constantly expanding at a very high pace and has become one of today's essential communication and information environments. But nevertheless, its potential as a facilitator of electronic commerce has not been fully realized. This is because today's networks are not secure enough for transmitting sensitive financial information. Despite the constant development of new encryption methods, they are seemingly never beyond a hacker's ability. Most users do not even want to take the chance of someone eavesdropping on their credit-card number or even postal address as it is carried along even the most secured network communication paths. The biggest problem for electronic commerce today is users' lack of trust and the psychological barriers to use of the Internet as a tool for commerce that arise therefrom.
Prior art systems have been developed in an effort to meet this need; for example, a system has been proposed called Secure Electronic Transaction (SET). With SET-enabled software and an account with a financial institution that supports the system, a user can go to an Internet World Wide Web (WWW) site, choose products to buy, and then order them with a few mouse clicks. The order is processed, the buyer's identity and account are verified, and the transaction is complete. Whether it's a checking or credit card account, or another payment system such as DIGICASH or FIRST VIRTUAL, it will be with a financial institution (such as MASTERCARD or VISA) that supports electronic payments, referred to as the Bank.
When a user opens the account, he receives from the Bank an electronic file called a certificate, which acts like a credit card for on-line purchases. It contains information about the user, including a public key, it has an expiration date, and it has been digitally signed by the Bank to ensure its validity. On the other end, merchants doing business with the Banks also get certificates that include both the merchant's public key and the Bank's public key. This certificate also is signed by the Bank to indicate that the merchant is legitimate. The merchant's key will be used for ordering, while the Bank's key will be used for paying.
The user indicates to the merchant what product or service he wishes to purchase via e-mail, through a Web page data transfer or the like. The following series of events is set in motion that takes a few seconds to complete. First, the user's software receives a copy of the merchant's certificate and verifies that it is dealing with a valid store since the certificate has been signed by the Bank. The user's software sends the merchant three items, all of which have been signed: the order information, which is encrypted with the merchant's public key; the payment information, which is encrypted with the Bank's public key (thus, the merchant cannot see the payment information); and a message digest (a code containing information from both the payment and the order) that ensures that the payment can only be used for that order.
After receiving these items, the merchant checks the user's digital signature. The merchant validates the user's information with a third party (likely, but not necessarily, the Bank) to make sure the user is genuine. The merchant then sends the user a message indicating that the order has been received. The merchant also sends a signed message to the Bank using the Bank's public key. This message includes the customer's payment information (which the merchant can't interpret) and the merchant's certificate.
The Bank first verifies that the merchant is legitimate, then checks the signature of the message it just received to make sure that the message is legitimate. The Bank then opens the enclosed payment information from the customer and verifies that it is good. The Bank also checks to make sure the payment information is for that merchant and that particular order. The Bank signs and encrypts an authorization to the merchant, which can then ship the goods.
The SET system has been criticized for various reasons, one of which is the possibility that a keystroke stealing program that attaches itself to the keyboard drivers in a user's computer can lay dormant until it is activated by the presence of a digital wallet program. It then records the keystrokes performed (before they are encrypted) and sends them to a third party. Such a phantom program could be disseminated inside a modified (but seemingly normal) electronic-commerce software package unknowingly distributed by a financial institution.
The SET methodology relied heavily on encryption, which is also another potential weakness. Certificates play a major part in SET's security scheme. The parameter that gives the certificates mathematical resistance to decryption is the length of the original encryption key. SET certificates will use a key 1,024 bits long, which is felt to provide strong enough security. But, as with any encryption-based scheme, a hacker can break the code given enough time and computing power. The problem with a total reliance on cryptographic methods is that if they are decrypted, they fail totally. Worse, if decryption is performed by a third party and goes undetected by the legitimate users, a false sense of security ensues. Stronger security for electronic transactions must have some sort of backup mechanism in place, rather than simple faith in a particular encryption scheme.
In another prior art electronic commerce scheme, the FIRST VIRTUAL system does not rely on any form of cryptography, rather it allows non-sensitive transaction information to travel over the Internet, while users' credit card numbers are gathered by phone. In addition, there is a buyer feedback mechanism built atop existing Internet application protocols including e-mail, FTP, telnet, and the World Wide Web. Because those protocols carry no proof of identity, FIRST VIRTUAL uses a payment system based on e-mail call-backs. When asked to process a financial transaction, it looks up the buyer's account and sends an e-mail message asking the buyer to confirm the validity of the transaction. The buyer can respond with "yes", "no", or "fraud". Only when the buyer says "yes" is a financial transaction initiated.
Moreover, FIRST VIRTUAL's dependency on e-mail and the "VirtualPIN" avails itself to a potential hacker's perusal for several reasons. First, e-mail is relatively easy to subvert, since it uses well known ports and can be "spoofed" or faked with simple tools and a rudimentary understanding of SMTP (Simple Mail Transfer Protocol). In addition, in the case of a slow e-mail gateway (such as that provided by most commercially available online services), mail delivery can take up to a day or more. Furthermore, the VirtualPIN is static and therefore can be impersonated.
A different scheme for electronic payments was developed by DIGICASH, based on a digital wallet containing tokens. The tokens are validated (digitally countersigned) by a bank, but the bank can't trace the tokens to an individual user,
None of the prior art systems provide a secure electronic commerce methodology sufficient to be carried out in large scale use over a non-secure network such as the Internet. Primary reasons for shortcomings of the prior art are the reliance on encryption as well as the transmittal of sensitive financial data over the Internet.
It is therefore an object of the present invention to provide a secure methodology and system for approving an online transaction carried out over the Internet by authenticating the identity and credit of the purchaser without transmitting a credit card number as part of the online transaction.
It is a further object of the present invention to provide such a system that does not rely on encryption for transmittal of data over the Internet as part of the transaction approval process.
It is a further object of the present invention to provide such a system that utilizes a third party as a trust broker that has users (purchasers) and vendors pre-registered, so that the trust broker may validate the transaction by authenticating the user by utilizing data internally stored that is not transmitted over the Internet.